perf(root): chunk state updates in state root task #14500
Draft
+213
−37
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…to alexey/state-root-task-state-update-chunk
shekhirin
force-pushed
the
alexey/state-root-task-state-update-chunk
branch
from
1c04532 to
a50c462
Compare
shekhirin
force-pushed
the
alexey/state-root-task-state-update-chunk
branch
from
8e2392b to
c20669f
Compare
|
link #14417 |
…k-state-update-chunk
…k-state-update-chunk
shekhirin
force-pushed
the
alexey/state-root-task-state-update-chunk
branch
from
b045ca9 to
ea68fa0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Given a state update with 100 accounts, it's preferred to spawn 20 multiproofs with 5 accounts each, instead of spawning one multiproof for all 100 accounts at once. The reason for that is that 20 multiproofs can be executed in parallel (even considering that they may do redundant work because of the intersecting trie nodes), while one multiproof will be executed serially for all accounts.
Same idea can be applied to storage slots: a state update with 1 account and 100 storage slots is better spawned as 5 multiproofs for 20 storage slots each, rather than one multiproof for all 100 storage slots at once.
This PR adds chunking on the
StateRootTaskside, so that every incoming state update is broken into multiple state updates, and spawned as a separate multiproof.